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ABSTRACT 


The  use  of  Computer  Aided  Design  (CAD)  tools  has  become 
increasingly  common  in  the  ship  design  and  manufacturing  industries  over 
the  last  decade.  These  tools  have  often  evolved  from  s  ma  I  I  individual 
efforts  developed  by  one  or  two  engineers  into  major  programs  on  which 
large  portions  of  the  ship  design  effort  depend.  In  many  cases  the 
management  of  the  computer  system  has  not  kept  pace  with  the  evolution  of 
the  s of t war e, 

This  paper  describes  an  approach  taken  to  the  d e v e I  o p me n t  of 
computer  systems  to  minimize  some  of  the  resulting  problems.  The 
underlying  premise  is  that  the  objective  of  the  system  is  to  increase  the 
overall  productivity  of  the  organization  instead  of  the  productivity  of 
any  single  technical  discipline.  The  conclusions  reached  were  that  more 
consideration  should  be  given  to  the  data  storage,  management  and 
communication  capabilities  of  current  computers  by  the  ship  design 
organizations  in  addition  to  the  effort  of  developing  design  or  analysis 
programs.  The  conceptual  system  design  that  resulted  from  applying  this 
approach  to  a  particular  organization  is  presented  along  with  a 
description  of  the  first  software  i  t  em  i  mpl  ement  i  ng  this  concept. 
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Section  1 


I  NTRODUCTI  ON 

The  use  of  Computer-Aided  Design  (CAD)  technology  has  become  a 
major  part  of  the  ship  design  and  manufacturing  projects.  The  programs 
being  used  have  evolved  from  small  simple  routines  to  complex  groups  of 
programs  that  work  together,  The  present  trend  is  towards  an  increasing 
reliance  on  computer  aids  to  the  ship  design  process,  These  systems  are 
expensive  to  implement  and  the  resources  for  their  development  are 
usually  limited,  We  are  now  faced  with  the  task  of  planning  and  managing 
the  further  development  of  these  aids  to  maximize  the  return  on 
i  n  v  e  s  t  me  n  t , 

The  technology  to  perform  the  separate  pieces  of  a  Itpaperless 
design",  exists  now,  that  is,  designing  a  ship  where  the  primary  means  of 
recording  and  manipulating  the  design  is  the  computer  system,  There  is 
potential  for  great  improvement  in  ship  design  productivity,  and  hence 
profitability,  with  a  paperless  design"  system,  However,  no  system  with 
all  the  separate  pieces  integrated  into  a  unified  systemhas  yet  been 
developed.  Some  factors  responsible  for  this  situation  are  the  cost  of 
such  a  system,  and  possibly  the  need  for  a  different  approach  to  their 
development,  In  particular,  the  management  of  ship  design  organizations 
must  realize  that  the  CAD  systems  are  essential  in  the  ship  design 
efforts  and  that  major  productivity  gains  are  possible  through  focusing 
management  attention  and  resources  on  those  systems, 

This  paper  will  discuss  an  approach  used  to  help  determine  where 
computer  technology  development  efforts  may  be  focused  to  provide  the 
greatest  improvements  in  the  productivity  of  the  overall  organization, 

We  will  then  briefly  describe  a  study  of  a  systemwhere  this 
approach  was  followed.  A  conceptual  integrated  systemdesign  reflecting 
the  conclusions  of  that  study  will  be  described.  The  software  efforts  to 
develop  the  data  management,  data  storage  and  communications  capabilities 
of  the  computer  system  for  CAD  will  be  presented, 
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Section  2 


APPROACH  TO  COMPUTER  AIDED  DESIGN  SYSTEMS 

This  section  presents  the  general  approach  SofTech  has  found  useful 
in  system  design  and  analysis  problems  in  both  the  Computer  Aided  Design 
(CAD)  and  Computer  Aided  Manufacturing  (CAM)  environments.  The  specific 
software  developed  may  have  limited  applications.  However,  the  approach 
may  be  found  useful  in  tackling  a  wide  variety  of  syst  em  pr  oduct  i  vi  t  y  and 
profitability  problems,  Later  sections  will  describe  the  results  of 
applying  this  approach  to  a  specific  task. 

2,  1  Def i  ne  the  Or  qani zat i  onal  Obi  set i ves 

The  first  step  in  the  design  of  any  system  is  to  develop  an 
understanding  of  the  objectives  of  the  organization  that  will  utilize  the 
system,  This  is  a  seemingly  obvious  step  but  surprisingly  it  is  rarely 
accompl  i  shed. 

Systems  for  Computer  Aided  Manufacturing  may  have  relatively 
straight-forward  objectives;  for  example,  to  double  the  production 
capacity  of  a  factory.  Computer  Aided  Design  systems  have  not  always  lent 
themselves  to  consideration  in  the  same  fashion.  It  is  not  easy  to  define 
the  productivity  of  a  design  organization,  as  the  product  is  often  not 
readily  quantifiable.  As  a  result,  many  times  programs  are  developed 
without  regard  as  to  whether  they  will  actually  improve  the  productivity 
and  profitability  of  the  overall  organization.  So  while  it  is 
technically  feasible  to  perform  a  great  many  functions  with  current 
computers,  the  first  step  is  to  determine'  the  criteria  of  the  overall 
organization  for  the  success  of  a  computer  system.  The  overall 
organization’s  point  of  view  in  many  cases  is  very  different  from  that  of 
the  design  engineers, 

An  analogy  that  may  be  useful  is  the  visualization  of  the  design 
organization,  a  collection  of  people,  hardware  and  software,  as  a  "black 
box"  system,  Resources  are  the  inputs  and  designs  are  the  outputs.  The 
organizational  objectives  may  be  to  increase  these  outputs  while 
ma  i  n t  a  i  n i  n g  a  constant  level  of  resource  inputs.  (Figure  2 - 1  ) . 
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Figure  2-1.  Black  Box 


The  process  of  determining  these  objectives  can  be  time  consuming. 
SofTech  usually  conducts  a  series  of  interviews  and  reviews  independently 
with  the  organization  management.  The  number  of  implied,  undocumented 
objectives  or  goals  "discovered"  during  this  process  is  often  surprising 
and  very  useful  to  the  managers. 


2.2  Understand  the  System 

Once  the  overall  objectives  are  defined  we  can  progress  to 
analyzing  the  system.  Through  studying  the  system  we  can  determine  how 
components  collectively  produce  the  design  as  an  output.  We  may  also 
begin  to  identify  problem  areas. 

There  are  often  many  people  who  will  say  that  they  understand 
exactly  how  their  design  process  works.  It  is  important  to  realize  that 
each  member  of  a  design  organization  may  have  a  different  view  of  how  the 
design  is  accomplished,  and  all  may  be  equally  correct.  Each  personnel 
role  in  the  design  system,  engineer,  manager,  and  administrator,  has  the 
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potential  for  a  different  viewpoint  of  the  system.  The  design  process 
may  consist  of  balancing  tradeoffs  to  a  design  manager,  while  it  is  a 
process  of  calculations  to  a  designer.  We  have  found  that  oftentimes  the 
viewpoint  of  the  organizational  manager  is  not  known  to  those  actually 
devel  oping  the  CAD  syst  e  ms , 

The  process  of  learning  a  system  is  akin  to  developing  a  schematic 
of  the  inside  of  our  previously  me n t  i  o n e d  "black  box."  (Figure  2 ■  2 ) . 

That  is,  we  develop  an  understanding  of  what  paths  and 
transformations  internal  to  the  system  are  necessary  to  develop  the 
output  of  the  system.  We  also  learn  what  areas  have  a  minimal  impact  on 
the  factors  we  are  interested  in.  In  fact  we  may  have  to  develop  a 
different  "schematic"  for  each  viewpoint  to  really  understand  how  the 
system  f  unct i ons , 


Fi  gure  2-  2,  Under  stand  t  he  Syst  em 
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2.3  Identify  Needs 

When  it  is  reasonably  certain  that  the  organizational  objectives 
and  the  nature  of  the  design  or  manufacturing  process  are  understood,  the 
"needs"  of  the  system  can  be  identified. 

By  the  term  "need"  we  mean  a  deficiency,  bottleneck  or  problem  in 
the  process,  If  we  think  of  the  design  process  as  a  black  box  with  a 

maze  of  interconnecting  pipes  linking  the  input  to  the  output,  the 

"need"  would  be  the  areas  of  restriction  of  the  flow.  These  may  be 
'blockages  or  malfunctions  or  other  items  that  may  be  functioning  properly 
but  are  of  insufficient  capacity.  (Figure  2-3). 

In  many  cases  the  "needs"  of  a  system  will  be  identified  during  the 

process  of  learning  how  the  system  works.  It  is  important  that  we 

evaluate  these  "needs"  on  the  basis  of  what  we  hope  to  accomplish.  In  our 
case  it  is  to  increase  the  overall  design  efficiency, 


a)  "Blockage" 


Figure  2  -  3 .  "Needs 
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2.4  Scoping  the  Syst  em 

In  most  cases,  there  are  more  problems  than  resources  available  to 
solve  them,  Therefore,  the  "needs"  must  be  prioritized  based  on  the 
overall  system  objectives,  In  the  analogy  of  the  "black  box"  system  only 
a  number  of  the  identified  blockages  can  be  improved.  It  is  our  job  to 
determine  which  efforts  will  provide  the  greatest  return  on  investment. 

Management  must  take  an  active  interest  in  this  step  of  the 
process,  There  are  limits  to  what  can  be  accomplished  with  a  fixed  level 
of  resources,  Often,  focusing  the  resources  on  one  area  may  do  more  to 
improve  productivity  than  attempting  to  apply  an  uni  f  or  m  ef  f  or  t  to  all 
the  problems,  At  this  time  the  management  can  often  be  made  aware  of  how 
much  their  system  can  be  improved  with  a  functioning  CAD  operation. 

2.5  For  mu  I  at  e  Solutions 

Once  areas  of  the  system  in  need  are  identified,  an  attempt  can  be 
made  to  formulate  a  solution  to  each  one.  This  is  much  easier  to  talk 
about  than  to  actually  accomplish.  Going  back  to  our  "black  box"  system 
anal  ogy  we  have  sever  al  choi ces. 

If  there  is  a  "blockage,"  or  malfunction  of  an  item,  we  can 
possibly  correct  it, 

If  there  is  an  area  of  insufficient  capacity,  we  can  enlarge  the 
capacity  of  the  existing  unit. 

The  third  possibility  is  to  change  the  syst  em  conf  i  gurat  i  on,  i  .  e .  , 
reroute  the  flow  or  change  the  boundaries  of  the  "box." 

It  is  impossible  to  supply  a  formula  for  developing  specific 
solutions,  Many  times  the  operational  staff  of  the  project  can 
contribute  a  great  deal  to  the  development  of  solutions  if  a  suitable 
forum  is  provided,  Our  (SofTech)  tasks  have  often  been  to  communicate 
the  "fixes"  envisioned  by  engineers  to  ma  n  a  g  e  me  n  t . 
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2 .  6  I  mp  I  e  me  n  t  Solutions 

Once  the  solutions  are  developed  they  may  be  subject  to  further 
changes  due  to  cost,  time  constraints  or  a  redefinition  of  the  overall 
objectives.  When  these  are  finalized  there  remains  the  problems  of 
implementation.  The  solution  may  be  writing  software,  acquiring  hardware, 
or  reorganizing  personnel  in  the  design  process.  Each  of  these  projects 
would  now  have  their  own  approach  to  accomplishing  a  more  defined  set  of 
detailed  obj  ect i ves , 

2 .  7  Eval  uat i  on 

Once  the  changes  are  made  to  the  system  they  should  be  evaluated 
with  respect  to  the  defined  organizational  objectives, 

"Did  the  items  implemented  accomplish  the  desired  objective?  And  if 
not,  why?” 

The  answer  may  be  outside  conditions  impacting  the  system  or  a 
failure  to  fully  understand  the  system  and  its  problems.  Establishing  a 
record  of  the  successes  and  failures  and  applying  that  knowledge  to 
succeeding  efforts  is  a  valuable  part  of  the  process,  This  body  of 

knowledge  provides  much  of  the  background  for  determining  the  potential 
returns  on  i t  ems  not  easy  to  quantify. 
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Section  3 


APPLI  CAT  I  ON  OF  APPROACH  TO  NAVSEA  55 

This  section  will  describe  the  results  of  applying  the  presented 
approach  to  a  task  of  improving  design  productivity  of  a  specific  ship 
design  organization.  The  organization  studied  was  the  Naval  Sea  Systems 
Command  (NAVSEA),  Code  55,  the  Hull  Design  Group. 

3.  1  Or  qani  zat  i  onal  Obj  ect  i  ves 

In  the  particular  project  being  discussed,  the  organizational 
obj  ect i  ves  were  st  at  ed  as: 

"to  achieve  an  increase  in  design  productivity  of  better 
than  five  to  one." 

The  reasons  for  establishing  this  objective  are  a  predicted  large 
increase  in  the  ship  design  workload  and  the  shortage  of  experienced, 
trained  naval  architects.  Not  only  are  there  governmental  personnel 
ceilings,  but  it  is  estimated  that  even  if  these  limits  were  relaxed 
there  are  simply  not  enough  trained  engineers  available  nationwide. 

Some  secondary  objectives  were  in  fact  constraints  to  the 
solutions.  They  are:  the  proposed  improvements  must  be  available  soon; 
they  must  not  disrupt  the  present  ship  design  process;  and  of  course,  the 
cost  must  be  mi  ni  mal  . 

3 .  2  The  NAVSEA  Des i  g n  Process 

The  engineering  system  studied  was  the  Hull  Design  Group  of  the 
Naval  Sea  System's  Command,  Code  55. 

This  organization  is  responsible  for  defining  the  g  e  o  me  t  r  y ,  or 
envelope,  of  a  ship,  This  includes  the  ship  structure,  internal  and 
topside  arrangements,  stability,  speed  vs.  power,  etc.  This  group  works 
closely  with  similar  organizations  having  responsibility  for  weapons, 
electronics,  and  machinery,  As  can  be  seen  from  the  following  paragraphs 
it  is  fairly  typical  of  a  ship  design  organization. 
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3.2.1  Desi  gn  Organi  zat  i  on 

The  Hull  Group,  NAVSEA  55,  organization  is  subdivided  into  smaller 
groups  by  a  functional  breakdown.  Each  organizational  group  is 
responsible  for  specific  sections  of  the  ship  design,  as  an  example,  one 
group  would  be  responsible  for  developing  the  ship's  hull  geometry.  As  a 
design  progresses  a  task  required  in  the  geometry  development  will  be 
assigned  to  an  engineer,  This  engineer  will  generally  continue  to  be 
responsible  for  this  task  throughout  the  many  iterations  of  the  ship 
design, 

Periodically,  the  ship  design  will  be  ltissued.il  This  means  that 
the  current  state  of  the  entire  design  at  that  point  in  time  will  be 
collected  and  approved  as  a  tt basel i  ne,  tt  At  these  steps  the  engineers' 
supervisor  will  be  responsible  for  the  approval  or  "sign-off"  of  a 
drawing  or  a  set  of  information,  The  aggregate  of  these  approved 
drawings  or  information  sets  comprises  the  "design." 

The  engineer  will  start  on  the  next  iteration  of  his  task  using 
this  "baseline"  package,  During  iterations  of  the  "baseline"  the 
engineer  will  communicate,  either  formally  or  informally,  with  other 
designers  to  obtain  more  up-to-date  information  or  information  not 
collected  into  the  f  o  r  ma  I  "issue," 

3.2.  2  Current  CAD  Sof  t  wa  r  e 

The  "typical"  engineer  may  perform  one  or  two  specific  design 
tasks,  If  supported  by  the  CAD  system,  these  tasks  will  usually  be 
performed  by  single  batch- type  programs,  or  stand-alone  interactive 
programs,  Programs  of  these  types  usually  have  defined  format  inputs,  and 
defined  f  o  r  ma  t  outputs.  Wh  e  r  e  necessary,  data  translation  is 
accomplished  by  "interface"  routines,  The  design  process  is,  therefore, 
a  collection  of  individual  p  r  o  g  r  a  ms  and  logically  separate  data  i  t  e  ms  in 
the  form  of  "files." 
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3.2.3  Hardware 

The  NAVSEA  computer  hardware  environment  includes  a  number  of 
separate  mainframe's  and  mi  n  i  -  c  omput  er  s .  Included  are  IBM,  CDC  and  DEC 
e  q  u  i  p  me  n  t  "linked"  via  file  transfer  capabilities  in  a  batch  mode. 

The  user  has  remote  access  to  these  systems  over  dial-up  phone 
lines,  usually  at  1  2  0  0  baud.  Terminals  include  TEKTRONIX  4014'  s,  "Dumb" 
CRT’s,  and  TTY  type  units, 

3.  3  Needs 

The  discussion  of  the  "needs"  of  a  design  organization  requires  us 
to  step  back  and  examine  the  process  from  some  distance. 

A  typical  design  organization  may  be  as  shown  in  Figure  3-1.  The 
organization  is  a  ordered  assemblage  of  people,  information  and  tools. 
The  people  may  be  design  managers,  administrators  or  engineers.  The 
information  consists  of  procedures,  or  how  things  are  accomplished  and 
data  about  the  particular  technical  subject.  The  tools  may  be  technical 
items  such  as  computer  and  programs  or  more  basic  items  like  drafting 
supplies  and  services, 

Obviously,  a  problem  with  any  one  of  these  areas  can  have  a 
negative  impact  on  productivity.  We  will  only  focus  on  those  areas 
potentially  suited  for  computer  support,  and  in  particular  those  related 
to  the  technical  design  i  nf  or  mat  i  on. 

The  elements  of  the  design  process  that  are  most  involved  with  the 
design  information  are  shown  in  Figure  3-2.  We  have  identified  the 
engineer  (circle),  the  ma  n  a  g  e  r  (square),  and  i  n  f  o  r  ma  t  i  o  n  (triangles). 
Arrows  show  typical  flows  of  information.  The  information  needed  for  a 
design  task  includes  procedures,  historical  data,  the  project  data,  and 
various  stages  of  approved  design  data. 
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Figure  3-1.  Design  Organization 
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Figure  3-2.  Elements  of  the  Design  Process 


When  considering  a  section  of  organization,  we  come  up  with  the 
picture  shown  in  Figure  3-3,  More  than  one  engineer  is  using  information 
and  there  are  a  large  number  of  data  flows,  Some  of  these  information 
transfers  are  of  the  program-to-program  type,  but  many  more  are  informal 
or  paper  t  r  ans  mi  1 1  a  I  s , 

The  evaluation  of  needs  for  this  project  was  performed  at  the  level 
shown  in  Figure  3-3,  The  question  posed  was:  "What  can  be  done  to  make 

this  system  of  information  derivation,  transfer  and  approval  work  more 
efficiently?",  The  evaluation  was  accomplished  by  examining  each  of  the 
elements  of  the  design  process  other  than  the  personnel, 

3.3.1  I  n f  o r  ma t  i  o n  "needs" 

The  i  n f  o r  ma  t  i  o n  "needs"  include  the  storage  and  retrieval  of 
procedures,  historical  data,  and  data  on  the  current  ship  design  project, 
and  the  flow  of  these  items  between  engineers, 

The  design  community  as  a  whole  does  not  have  common  procedures  for 
the  automated  storage  and  retrieval  of  technical  information,  The  entire 
area  of  developing  a  usable,  responsive  system  of  data  handling, 
communication,  and  storage  for  a  large  organization  needs  to  be 
addressed,  Items  of  particular  attention  are:  storing  and  protecting 
approved  drawings  and  design  items;  providing  communication  among 
engineers,  between  engineers  and  managers;  and  standardization  of  data 
storage  between  departments, 

3.3.2  Tools  "needs" 

The  subject  of  tools  includes  task-speci  fi  c  items  such  as  computer 
programs  and  system- wide  tools  such  as  computers, 

One  of  the  major  "needs"  identified  was  the  scattering  of 
operations  among  many  different  computers,  This  has  resulted  in 
different  sets  of  software  for  each  machine  and  different  procedures  for 
its  use  from  one  mac  hi  ne  to  another, 
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Figure  3-3.  The  Design  Process 


"Needs"  in  the  area  of  specific  tasks  were  found  to  be:  to 
increase  the  utility  of  existing  programs  by  making  them  more 
“user-friendly,"  and  the  continued  devel  opment  of  specific  p  r  o  g  r  a  ms , 
Another  problem  area  was  the  support  or  maintenance  of  the  software 
already  developed.  In  short,  many  independent  applications  programs  are 
available  but  other  factors  render  them  less  useful  than  they  might 
ot  herwi  se  be, 

The  "needs"  identified  here  are  typical  of  many  current  design 
organizations.  Present  systems  are  the  products  of  evolution  and  the  work 
of  many  engineers  working  independently.  The  result  is  many  independent 
programs  working  correctly,  exactly  as  they  were  supposed  to.  The  "need" 
or  problem  has  only  occurred  because  advances  in  technology  have  ma d e 
much  mo r e  capability  feasible, 

3.  4  Scope 

The  problems  identified  were  of  the  following  categories: 

•  Insufficient  or  inadequate  application  programs, 

Overal I  system  hardware, 

I  Communi  cat  i  ons  among  engineers, 

Ease  of  use  of  the  computer  system, 

Data  storage,  and 

Lack  of  common  system  desi gn, 

In  evaluating  the  "needs"  versus  the  objective  of  a  f  i  v  e  - 1  o  -  o  n  e 
increase  in  productivity  it  is  clear  that  adding  one  or  mo  r  e  independent 
p  r  o  g  r  a  ms  cannot  possibly  provide  the  necessary  increase.  The  only  course 
left  is  to  tackle  the  system- wide  areas  and  make  use  of  current  advances 
in  communications,  data  storage  and  management, 

It  was  decided  that  while  application  programs  were  being 
developed,  a  concurrent  project  would  work  towards  a  common  hardware, 
software,  and  management  environment, 
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3.5  Solutions 


The  major  proposed  solutions,  or  items  thought  to  provide  an 
overall  increase  in  syst em  pr oduct i  vi t y,  were: 

a  Move  all  operations  onto  one  hardware  facility.  This  would 
eliminate  much  of  the  communications  difficulties  and 
differences  in  operations,  and  provide  for  easier 
ma  i  n  t  e  n  a  n  c  e  and  support. 

I  Provide  a  dedicated  syst  em  support  group  for  syst  em  cont  rol , 

software  development  and  maintenance,  and  hardware 
operation.  This  would  alleviate  much  of  the  burden  on  some 
design  engineers  and  provide  mo  r  e  reliable,  consistent 
servi  ce  throughout , 

Develop  an  overall  integration  concept  for  data  and  programs 
utilizing  current  communications,  data  management  and 
control  capabilities.  This  would  be  the  start  of  evolution 
towards  an  integrated  system  providing  ease  of  use  to  the 
engineers, 

3.6  S  election  of  I  mpl  ementati  on  I  t  e  ms 

The  study  determined  several  possible  improvements  to  the  design 
process,  As  with  any  system,  cost  and  other  constraints  determine  which 
i  t  ems  are  i  mpl  ement  ed. 

In  this  case,  while  most  engineers  agree  on  the  benefits  of  moving 
operations  to  one  computer  system,  it  may  not  be  an  easy  thing  to 
accomplish.  Similarly,  changes  in  the  design  process  such  as  adding  a 
software  support  function  are  also  difficult  to  effect. 

SofTech  was  tasked  to  begin  work  on  the  third  proposal,  to  plan  for 
an  integrated  system  of  people,  software  and  hardware.  This  solution  was 
further  constrained  by  the  requirement  for  rapid  implementation  and 
minimal  disruption  of  ongoing  work.  This  has  resulted  in  a  conceptual 
system  design  and  a  prototype  program  to  improve  data  management  and 
program  utility.  The  software  item  is  referred  to  as  the  "File  Manager." 
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PROPOSED  SYSTEM  DESI  GN 

In  this  section  the  system  design  concept  will  be  described.  This 
design  is  an  attempt  to  develop  an  integrated  system  of  people,  software 
and  hardware.  It  is  based  upon  a  low-cost,  I  ow- di  s  r  u  pt  i  on  evolution  from 
the  present  computer  aided  design  environment, 

4.1  D esi  qn  Consi  derat  i  ons 

Before  we  can  specify  a  solution  to  the  problems  some  discussion  of 
the  available  and  forthcoming  advances  in  CAD  technology  is  appropriate, 
The  field  is  developing  so  rapidly  that  it  is  difficult  to  implement  a 
system  before  advances  render  it  obsolete.  This  section  will  discuss  some 
of  the  considerations  and  technological  advances  that  must  be  taken  into 
account  when  planning  a  Computer-Aided  Design  system, 

4.1.1  Dr  awi  nq  Based  System 

In  the  traditional  design  process,  based  upon  individual  drawings, 
there  is  limited  indexing  and  cross  referencing  of  information.  A 
particular  drawing  may  be  catalogued  by  title,  drawing  number  and 
revision  date.  Information  describing  separate  pieces  of  the  ship  that 
are  shown  on  the  drawing  might  be  detailed  in  another  drawing.  In 
general,  though  there  is  no  cross-referencing  between  drawings  for  a  more 
detailed  description  of  parts  of  the  design  (Figure  4-1), 

Off-the-shelf  drafting  computer  systems  that  can  automate  the 
drawing  process  are  available.  These  systems  do  not  necessarily  change 
any  of  the  operations;  they  are  essentially  an  electronic  drafting  board 
and  dr  awi  ng  file, 


TP  137 


95 


TP  137 


VO 

CTi 


Figure  4-1.  Drawing  Based  System 


4.1.  2  The  Computer  System  as  the  Design  Media 

For  the  last  hundred  years  ship  designs  have  been  performed  using 
the  drawing  as  the  means  of  recording  design  information  and 
communication  between  engineers  and  managers.  There  now  exists  an 

alternate  medium  to  serve  these  functions,  the  computer  system.  While 
illustrations  will  not  be  replaced  for  the  communication  of  concepts  to 
individuals,  it  is  likely  that  the  primary  means  of  recording  information 
will  become  the  computer  system,  since  it  offers  instant  access,  change, 
distribution  and  control  of  i  n  f  o  r  ma  t  i  on  not  available  to  a  "hard”  me  d  i  a . 
This  transition  is  already  underway,  and  when  it  occurs  without 
management  awareness  it  may  be  the  source  of  problems  during  ship  design 
pr oj  ect s , 

If  we  accept  the  premise  that  the  design  will  eventually  be 
performed  using  the  computer  system  as  the  media,  we  must  try  to 
determine  what  are  the  implications  of  this  change  and  how  they  might  be 
managed. 

The  properties  of  the  computer  system  that  provide  its  benefits  are 
the  same  ones  that  may  cause  new  areas  of  concern.  These  are:  ease  and 
speed  of  changing  i  n  f  o  r  ma  t  i  o  n ,  the  ability  to  correlate  or  "track" 
information  from  many  different  viewpoints,  the  ability  to  use  the 
computer  as  a  communications  center,  the  ability  to  store  large 
quantities  of  information,  and  the  ability  to  perform  computations 
directly  on  the  design  data.  All  of  these  different  "viewpoints"  and 
capabilities  require  management,  For  example,  the  organization  must 
control  who  can,  or  cannot,  change  information, 

Additionally,  we  must  always  remember  that  the  system  will  only  do 
exactly  what  we  tell  it  to  do.  Formulating  the  correct  directions  to  the 
system  is  the  pr  obi  em, 
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4.1.3  Correlation  of  I  nf  or  mat  i  on 


The  computer  system  provides  a  great  deal  of  information  storage 
capability.  Possibly  more  useful  than  the  quantities  of  data  stored,  are 
its  ability,  when  working  with  database  software,  to  provide  many 
different  means  of  indexing  or  accessing  information.  Each  information 
item  in  the  computer  may  have  associated  with  it  one  or  more  parameters 
to  facilitate  the  recalling  of  that  stored  information.  When  the  same 
information  is  used  by  different  people,  a  separate  parameter  may  be 
assigned  each  person,  We  term  the  p  a  r  a  me  t  e  r  s  that  a  person  uses  to 
organize  his  storage  and  recovery  of  information  his  Viewpoint." 
Potentially,  there  are  as  many  different  viewpoints  as  there  are  users  of 
the  information.  Therefore,  in  the  computer  system  we  cannot  simply  keep 
track  of  a  number  of  drawings,  we  must  manage  the  requirement  to  access 
the  information  in  many  different  fashions. 

4.1.4  Pi  r  ect  i  nq  the  Comput  er  System 

The  computer  is  a  very  powerful  tool  for  engineering  purposes  with 
one  major  challenge.  The  user  must  direct  the  computer  to  perform  his 
functions  by  specifying  a  series  of  very  small  computational  steps.  One 
cannot  store  information  in  the  computer  without  specifying  exactly  how 
it  will  be  stored  and  the  ways  it  may  be  recalled.  Database  packages  will 
help  with  the  mechanics  of  this  process  but  will  not  help  with  the 
specification  of  what  is  to  be  stored  or  how  it  will  be  recalled.  The 
development  of  this  specification  requires  that  we  decide  in  what  units 
the  information  will  be  stored,  or  how  big  the  groups  are,  by  what 
methods  may  the  data  be  recalled,  and  how  the  information  is  related  to 
other  stored  data.  This  must  be  specified  for  every  identifiable  type  of 
itemthat  will  be  stored  in  the  computer.  Developing  this  description  of 
the  design  information  can  require  a  great  deal  of  effort.  This 
description  is  sometimes  referred  to  in  database  terminology  as  a 
11  s  c  h  e  ma . " 
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4.1.5  Co  mput  er  Database  De  s  i  q  n  System 

Computer  systems  have  the  potential  for  vastly  increasing  the  level 
of  detail  of  the  breakdown  and  storage  of  information.  These  systems 
differ  from  the  "electronic  drawing  board"  in  that  information  about 
i  t  e ms  of  the  ship  design  are  stored  separately.  Wh e n  i  n f  o r  ma t  i  o n  or  an 
illustration  is  required,  the  desired  data  is  selected  fromthese 
separate  items  and  presented  in  the  desired  format  (Figure  4-2), 

This  approach  has  the  potential  for  a  great  deal  mo  r  e  flexibility 
and  a u t  o ma t  i  o n  of  the  design  effort.  For  instance,  once  the  locations  of 
hull  equipments  and  weights  are  entered,  this  system  could  perform  the 
moment  calculations  directly  from  the  stored  data, 

4.1.6  Subdivision  of  the  Design  Data 

One  of  the  maj  or  pr  obi  ems  in  developing  a  CAD  system  is  det  er  mi  ni  ng 
how  to  organize  and  subdivide  the  stored  data,  Wi  t h  a  finer  " me s h , "  i  ,  e , 
greater  detail,  there  is  more  potential  for  automation  of  functions  and 
non- r  edundant  storage  of  information,  commonly  termed  integration.  On  the 
other  hand,  a  coarse  "mesh”  provides  fewer  separate  groups  of  information 
to  manage, 

Current  database  software  enables  the  usage  of  the  finer  mesh  from 
a  software  viewpoint,  However,  these  databases  do  not  solve  the  problems 
of  managing  the  ship  design  information  at  this  greater  level  of  detail. 

The  main  impediment  to  developing  an  integrated  system  is  the 
limited  techniques  for  managing  the  greater  numbers  of  items  that  would 
now  compr  i  se  the  design, 

4.1.7  The  Electronic  Des  i  gn  Of  f  i  c  e 

If  we  accept  the  premise  that  the  computer  system  will  become  the 
design  media,  we  arrive  at  the  concept  of  the  "electronic  design 
office",  That  is,  we  must  implement  many  of  the  functions  that  we  take 
for  granted  in  a  paper  -  or  i  ent  ed  office  as  part  of  the  computer  system, 
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Figure  4-2.  Database  System 


For  example,  as  design  projects  and  staffs  have  grown  larger  and 
more  complex,  the  methods  of  management  have  not  changed.  In  the  past, 
design  decisions  could  be  considered,  action  taken,  and  information 
distributed  by  a  small  group  of  personnel  looking  over  a  set  of  drawings, 

In  the  future  this  function  must  be  performed  by  operating  on 
ma  c  h i  n  e - s  t  o  r  e  d  data,  and  instructing  the  s  y  s  t  e  m  t  o  p  e  r  f  o  r  m  t  h  e  necessary 
distribution, 

The  current  data  storage  systems  can  implement  the  drawing  file  and 
very  importantly,  track  all  of  the  drawing  changes  and  revisions,  The 
engineering  system  can  be  implemented  so  that  each  designer  has  not  only 
his  own  hardware  workstation,  or  drafting  table,  but  his  own  storage 

areas  free  from  outside  intrusion  as  well, 

The  computers  communications  capability  can  perform  the  rapid 
distribution  of  new  "prints"  of  a  drawing  to  widely  scattered  designers, 

It  may  also  provide  the  ability  to  hold  a  drafting  board  review  over 
different  terminals,  A  drawing  with  informal  notes  can  be  transmitted  to 
another  engineer  with  the  same  ease  that  formerly  was  used  to  bring  it 
across  the  room, 

There  are  a  large  number  of  functions  performed  in  a  design  office 

that  are  not  design  or  analysis,  In  fact,  too  little  of  the  designer's 

time  is  spent  in  engineering,  Much  of  their  time  is  spent  chasing  down 
information,  sitting  in  meetings,  setting  up  input  data  and  fighting 
unruly  computers,  Technology  available  only  in  the  last  few  years  can 
help  expedite  much  of  these  efforts;  except,  probably,  the  meetings, 

The  proposed  approach  must  answer  "How  will  this  be  implemented?" 

4,  2  Syst  em  Desi  gn 

The  system  design  presented  here  stems  from  the  specified 
requirements  and  the  aforementioned  considerations,  The  requirements  are 
that  it  provide  an  increase  in  productivity;  be  available  soon;  be  low 
cost;  be  compatible  with  existing  operations  software  and  data,  and  be 
easy  to  use,  The  other  considerations  determine  in  which  direction  we 
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would  like  to  evolve,  The  system  should  be  compatible  with  the  present 
drawi  ng-  based  method  of  design,  but  provide  a  transition  towards  a 
database  concept,  it  should  accommodate  a  fine  data  "mesh"  as  well.  It 
should  be  able  to  accommodate  multiple  viewpoints  of  different 
personnel,  It  should  evolve  towards  the  "electronic  design  office"  where 
the  computer  serves  as  the  media  for  the  design, 

The  "integration  approach"  is  an  attempt  to  solve  this  family  of 
p  r  o  b  I  e  ms , 

The  dr  awi  ng- bas  ed  system  shown  in  Figure  4-1  provides  compatibility 
with  some  of  the  existing  software  and  methods.  It  essentially  automates 
the  drafting  tasks,  and  ma  y  have  a  separate  system  for  analysis. 

However,  this  system  does  not  provide  for  evolution  to  a  direct 
integration  of  anal  ys  i  s- 1  o- des  i  gn  as  the  drawings  are  the  only  record  of 
the  design, 

The  database  system  of  Figure  4-2  provides  more  evolutionary 
capability,  It  allows  drawings  to  be  generated  from  a  central  record  of 
the  ship  design,  In  fact  it  a  c  c  o  mp  I  i  s  h  e  s  all  of  the  desired  functions, 
but  only  theoretically,  The  performance  and  management  problems  with 
systems  of  this  type  have  limited  their  successful  use  to  very  small 
operations, 

The  proposed  system  is  shown  in  Figure  4-3.  Essentially  this  uses 
the  same  element  as  the  database  system,  We  will  store  information  about 
the  ship,  not  records  of  lines  that  describe  the  ship's  components.  The 
difference  is  that  the  database,  and  the  control  of  the  data  is 
distributed  to  match  the  project  structure. 

The  data  is  broken  into  the  fine  "mesh"  suitable  for  highly 
integrated  programs  and  data  access,  but  it  is  grouped  in  sets  small 
enough  to  be  manageable,  This  approach  is  feasible  because  in  the  design 
process  there  is  very  little  requirement  for  great  detail  other  than  to 
the  staff  directly  responsible  for  a  s e g me n t  of  the  design,  The 
distribution  of  the  database  in  this  fashion  also  removes  many  of  the 
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Figure  4-3.  Proposed  System  Design 


physical  performance  limitations.  In  addition,  the  system  includes  a 
management  system  to  keep  track  of  this  distribution,  and  to  provide  for 
the  essential  transfer  of  information  between  groups. 

4.2.1  Data  Structure 

The  tradeoff  presented  is  that  of  a  fine  "mesh"  or  subdivision  of 
data  items  for  program  integration  and  flexibility  versus  a  coarser 
"  me  s  h "  that  is  f  a  mi  I  i  a  r  to  engineers  and  is  easier  to  ma  n  a  g  e . 

The  selected  integration  approach  is  to  have  a  different  level  of 
subdivision  for  management  purposes  from  that  used  for  the  software  data 
access.  The  management  subdivision  will  be  much  the  same  as  the  present 
drawing  level  of  detail.  The  software  storage  of  data  will  start  off  with 
the  current  file  access  methods  and  evolve  toward  a  database  system. 

The  key  to  understanding  the  approach  is  that  the  physical 
implementation  of  the  information  on  the  computer  does  not  have  to  match 
the  user's  perspective  of  that  information.  Although  an  engineer  may 
wish  to  see  all  the  ship's  geometry  information  at  one  time,  that  does 
not  require  that  all  the  information  be  stored  in  the  same  place,  or  even 
in  the  same  manner.  What  is  required  is  that  the  engineer  have  an 

access- met  hod  to  the  data  that  will  yield  the  desired  result.  Allowing 
different  access  methods  or  viewpoints  to  the  same  information  gives  us 
the  flexibility  to  have  both  t  he  fine  and  the  coarse  mesh  we  need  for  the 
design  process. 

The  approach  of  distribution  of  data  and  its  control,  while 
maintaining  a  separate  management  system,  provides  the  capability  to 
transition  smoothly  from  current  software  to  the  "electronic  office." 

The  management  system  may  be  implemented  by  treating  each  type  of  present 
data  file  as  a  separate  database  or  database  segment.  The  existing  data 
access  me t  h o d s  can  be  utilized  until  the  r  e q u i r  e me n t  for  a  finer  " me s h " 
or  other  needs  dictate  a  change.  Thus,  existing  data  access  methods  can 
be  used  side-by-side  with  newer  database  techniques,  with  the  management 
system  handling  the  switching  between  them. 
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Perhaps  an  analogy  to  a  large  engineering  library  will  convey  the 
concept  more  clearly.  If  the  library  has  only  one  librarian,  and  the 

books  are  cataloged  by  a  system  known  only  to  that  librarian  we  have  the 
case  of  a  central  database,  If  the  librarian  is  very,  very  fast  users 

may  get  what  they  need.  If  the  librarian  is  not  fast,  there  will  be 

undesirable  delays, 

The  present  system  is  that  of  having  many  separate  libraries.  Each 
has  books  on  one  or  more  subjects,  and  overlaps  exist.  Moreover  there 

are  no  librarians,  only  users  of  the  different  libraries  who  may  or  may 
not  be  available  to  help  others, 

The  proposed  system  includes  the  establishment  of  separate 
libraries  and  cataloging  them,  but  keeping  individual  indexes  for  each 
one,  A  central  librarian  directs  the  user  to  a  librarian  in  charge  of 
the  particular  section  he  requires,  From  then  on  the  user  will  work 
directly  with  that  local  librarian,  In  our  case  we  follow  the  same 
sequence  for  storing  information  as  well. 

4.2.  2  Program  Structure 

The  conceptual  design  is  a  system  of  computer  programs,  engineers, 
databases  and  management, 

The  computer  programs  of  the  system  design  would  be  similar  to 

those  currently  in  use,  The  trend  has  been  for  programs  to  increase  in 

size  and  complexity.  This  has  come  about  mostly  because  of  the 

difficulty  of  data  access  and  management.  The  engineer  pulled  in  an 
entire  "management  unit”  of  information  and  performed  his  operations  on 
it, 

The  conceptual  system  design  calls  for  the  development  of  smaller 
programs  performing  one  or  two  functions,  These  programs  are  easier  to 

implement  with  database  technology  and  may  be  "  st  r  ung"  t  oget  her  to 
achieve  the  s  a  me  results  as  the  larger  p  r  o  g  r  a  ms ,  if  required, 
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4.2.3  Enqi  neer  s  Vi  ewpoi  nt 

The  proposed  system  wi  I  I  allow  the  engineer  to  function  in  the  same 
manner  as  they  do  now,  with  the  substitution  of  the  computer  terminal  for 
the  drafting  board. 

The  engineer  will  be  responsible  for  individual  tasks.  These  will 
be  accomplished  by  design,  analysis  or  drafting  programs.  The  engineer 
will  have  complete  control  over  his  information,  and  will  be  able  to 
per  mi  t  or  restrict  access  as  he  desires, 

4.2.  4  Des i  q n  Managers 

The  project  managers  will  be  responsible  for  approving  design 
information  stored  on  the  computer  and  for  directing  analyses  or  changes 
to  the  design,  Therefore,  the  system  must  be  able  to  record  and  "freeze" 
information  on  approval,  There  must  be  the  computer  equivalent  of 
setting  a  "baseline"  of  a  design. 

Change  directives  must  also  be  coupled  with  the  design  data.  If  a 
change  based  upon  a  drawing  or  report  is  directed,  that  particular 
collection  of  data  must  not  vanish  when  the  engineer  performs  his  next 
update,  The  recordkeeping  that  goes  along  with  the  drawing  system  must 
be  i  mpl  ement  ed  on  the  comput  er . 

4.2.5  Data  Ad  mi  n  i  s  t  r  a  t  i  o  n 

With  the  development  of  software  to  manage  data  storage,  a  data 
administration  function  must  be  initiated.  The  subdivision  of  data,  its 
place  in  the  databases,  and  its  retrieval  methods  cannot  be  readily 
distributed. 

This  function  is  analogous  to  the  setting  up  of  the  central 
librarian,  who  in  turn  will  hire  and  manage  the  supporting  specific 
librarians, 
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4.2.6  Program  Development  and  Maintenance 

Developing  programs  under  this  sytem  should  be  simpler  because  of 
the  separation  of  data  access  methods  from  the  programs.  By  referring  to 
the  data  administration  documentation,  programs  may  call  previously  set 
up  data  access  methods, 

As  the  data  access  methods  are  central  to  the  entire  system, 
control  will  have  to  be  exercised  over  their  operation,  Independent 
software  developments  must  be  checked  for  authority,  security  and  project 
control  before  allowing  data  to  be  changed. 

4.3  F  i  I  e  Manager 

The  "File  Manager”  is  a  program  being  developed  to  aid  in  the  use 
of  the  computer  aided  design  program  and  to  help  manage  the  design  data, 
Its  objective  is  to  remove  the  need  to  know  any  specific  computer 
language  or  operations  fromthe  engineer  .  It  is  designed  to  be  the  first 
step  toward  the  management  part  of  an  integrated  system  of  programs  and 
data.  The  first  "BUILO"  of  the  program  is  now  in  operational  evaluation 
and  test,  updates  and  extensions  are  planned  to  result  in  "BUILD  TWO"  by 

the  Spring  of  1983, 

The  present  environment  utilizes  data  files  stored  by  different 
naming  conventions  on  each  computer,  For  example,  some  conventions  limit 

the  user  to  a  s  e  v  e  n - 1  e  1 1  e  r  f  i  I  e  n  a  me .  The  overhead  involved  as  the 
engineers  learn  the  computer  file  manipulation  commands  and  track  their 
files  has  become  a  noticeable  problem, 

4.3.1  File  Manager  Data  Structure 

The  File  Manager  (FM)  provides  a  structure  to  aid  the  engineer  in 
the  storage  and  recall  of  ship  design  information.  The  database  is 
divided  into  ship  design  projects,  ship  design  variants  inside  a  project, 
and  files  that  are  parts  of  a  particular  design.  Files  that  are  part  of  a 

design  are  further  categorized  by  their  approval  status.  They  may  be 
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approved  files,  i .  e,  files  that  constitute  a  design  baseline.  Other 
classifications  include  "past  approved  files"  and  proposed  files 
representing  previous  baselines  and  the  target  for  the  next  baseline, 
respectively. 

There  will  also  exist  "private  files"  directly  under  the  control  of 
the  design  engineers  as  part  of  the  design.  One  engineer  may  work  on  many 
projects  or  designs,  but  a  particular  file  of  information  will  only  be 
associated  with  one  design  (Figure  4-4).  The  File  Manager  will  manage 
information  about  existing  files  at  a  management  level.  As  new  software 
is  developed  the  file  manager  will  be  extended  to  include  the  separation 
of  programs  from  data  access  routines. 

4.3.2  File  Manager  Pat  a  Handl  i  ng 

The  file  manager  will  provide  each  engineer  with  the  ability  to 
add,  delete,  rename  and  search  for  files  by  using  simple  commands 
selected  from  a  menu.  For  example,  the  engineer  may  request  a  list  of  all 
files  owned  by  an  engineer,  or  all  files  of  a  certain  type,  or  all  files 
wr  i  1 1  en  on  a  specific  date, 

More  importantly,  the  system  will  deal  in  terms  that  have 
significance  to  the  engineer,  The  system  will  remove  all  "computerese" 
from  the  interaction  with  the  user,  It  will  at  the  same  time  permit 
sophisticated  operations  to  be  performed. 

4.3.3  File  Manager  Program  Interface 

The  file  manager  will  provide  a  means  for  the  engineer  to  initiate 
a  programs  operation  by  choosing  simple  commands  from  a  menu  presented  to 
him.  The  systemwill  ensure  that  only  the  correct  type  of  files  are  used 
as  input  to  each  program,  and  that  they  are  of  the  same  design  as  is 
currently  being  performed. 
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Figure  4-4.  File  Manager  Data  Structure 


Section  5 


SUMMARY 

The  conclusions  of  our  study  are  that  in  some  ship  design 
environments  the  best  return  on  an  investment  in  computer  aided  design 
technology  may  be  in  integrating  existing  software.  This  is  to  some 
extent  dependent  upon  the  size  of  the  design  organization,  as  s ma I  I  e r 
groups  do  not  have  the  same  management  problems. 

The  integration  approach,  or  conceptual  design  offers  a  transition 
from  current  methods  towards  a  database  system  or  "electronic  design 
office"  (Figure  5-1),  The  approach  will  smooth  the  transition,  allow 
easier  acclimation  of  users,  and  more  gradual  cost  of  implementation.  it 
will  lessen  the  work  involved  by  allowing  us  to  learn  as  we  go  along 
instead  of  plunging  headlong  into  a  major  CAD  system  re-write. 

We  believe  that  a  similar  approach  toward  increasing  productivity 
or  profitability  may  be  applicable  to  a  number  of  other  design  or 
manufacturing  environments,  where  compatibility  with  existing  operations, 
evolution  towards  advanced  systems  and  gradual  implementation  are 
i  mpor  t  ant  considerations, 


'J  Organizations  must  focus  on  the  best  return  on  their 

CAD  i  nves  t  me n t , 

'J  The  trend  is  towards  the  ^Electronic  Design  Office", 

the  comput  er  is  the  design  medi  a. 

•J  It  is  possible  to  plan  a  smooth  transition  from  current 
systems  to  the  "Electronic  Design  Office" 


Figure  5  - 1  .  S  u  mma  r  y 
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